Intelligent spatial enterprise analytics

ABSTRACT

For distributed analysis of time-series data in a smart entity environment, the data is received from a data source in the environment. An overall analysis of the data is distributed to a first node in the environment. In a network operating the environment the first node is at a smaller distance from the data source as compared to a second node. A first portion of the overall analysis is performed on the data at the first node to produce a first conclusion. The first conclusion is routed to the second node. The second node performs a second portion of the overall analysis. Using the first conclusion, from the first node, a first action is caused to occur on a component of the environment. The data source is associated with the component, the data is indicative of a condition in the environment, and the component participates in the condition.

TECHNICAL FIELD

The present invention relates generally to a method for distributed dataanalysis. More particularly, the present invention relates to a methodfor intelligent spatial enterprise analytics for smart entityapplications.

BACKGROUND

Initiatives are being implemented at buildings and structures level tocity, township, district, state, and national level to achieve orincrease economic growth, operational efficiency, sustainabledevelopment, and societal progress. These initiatives are commonlyreferred to as smart planet initiatives, smart city initiatives, smartbuilding initiatives, and other such names (collectively referred tohereinafter as smart entity initiative or smart entity initiatives). Theentities implementing these initiatives are correspondingly referred toas smart city, smart building, etc. (collectively referred tohereinafter as smart entity or smart entities).

As an example of smart city initiatives, cities are increasingly turningto analytical software systems to solve a variety of problems. Thenature of these problems varies from optimizing emergency response,detecting possible issues in an electric grid, to identifying trends andpatterns in citizen behavior.

Consider, as an example, the infrastructure of a city, which includescomplex systems such as the electric grid and its thousands or millionsof components, the traffic management system and its thousands ormillions of components, and many other systems or networks.

These thousands or millions of components further include millions ofsub-components that generate data of various types and for variouspurposes. For example, transformers in the electric grid havetemperature monitoring sensors that produce and transmit transformertemperature data. This data is generated periodically, on a schedule,upon certain events, or a combination thereof.

SUMMARY

An embodiment includes a method for distributed analysis of time-seriesdata in a smart entity environment. The embodiment receives, from a datasource in the smart entity environment, the time-series data. Theembodiment distributes, in the smart entity environment, an overallanalysis of the data to a first analytics node, wherein in a networkoperating the smart entity environment the first analytics node is at asmaller distance from the data source of the time-series data ascompared to a distance between the data source and a second analyticsnode. The embodiment performs on the time series data, at the firstanalytics node, a first portion of the overall analysis to produce afirst conclusion. The embodiment routes the first conclusion to thesecond analytics node, wherein the second analytics node performs asecond portion of the overall analysis. The embodiment causes, using thefirst conclusion, from the first analytics node, a first action to occuron a component of the smart entity environment, wherein the data sourceis associated with the component, wherein the time-series data isindicative of a condition in the smart entity environment, and whereinthe component participates in the condition.

Another embodiment includes a computer usable program product comprisinga computer readable storage device including computer usable code fordistributed analysis of time-series data in a smart entity environment.

Another embodiment includes a data processing system for distributedanalysis of time-series data in a smart entity environment.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

The novel features believed characteristic of the invention are setforth in the appended claims. The invention itself, however, as well asa preferred mode of use, further objectives and advantages thereof, willbest be understood by reference to the following detailed description ofthe illustrative embodiments when read in conjunction with theaccompanying drawings, wherein:

FIG. 1 depicts a block diagram of a network of data processing systemsin which illustrative embodiments may be implemented;

FIG. 2 depicts a block diagram of a data processing system in whichillustrative embodiments may be implemented;

FIG. 3 depicts a block diagram of a presently used configuration fordata analysis that can be improved by an illustrative embodiment;

FIG. 4 depicts an example distributed iSEA configuration according to anillustrative embodiment;

FIG. 5 depicts a representative illustration of speed and costadvantages of iSEA in accordance with an illustrative embodiment;

FIG. 6 depicts a flowchart of a process for distributed analytics usingstandard form analytic functions in an iSEA configuration according toan illustrative embodiment; and

FIG. 7 depicts a process for creating an analytics configuration fordistributed analytics of data using standard form analytics functions inaccordance with an illustrative embodiment.

DETAILED DESCRIPTION

A smart entity application is a software application including code orsoftware instructions, which when executed by a processor using amemory, causes a function of an embodiment described herein to beperformed in facilitating or improving an implementation of a smartentity initiative by a smart entity on a smart entity system. A smartentity system is a data processing system on which a smart entityapplication, such as an analytic agent described herein, executes. Asmart entity environment is a data processing environment that includesa plurality of smart entity systems spatially distributed at differingdistances from primitive data sources on which a plurality of smartentity applications execute. In the smart entity environment, zero ormore smart entity systems can be interspaced between a particularprimitive data source and a particular smart entity system. Primitivedata sources are also a part of the smart entity environment.

Data originally emitted by a data source is called primitive data.Accordingly, the data source that produces primitive data is called aprimitive data source. In statistics, signal processing, and many otherfields, a primitive data is a sequence of data points—a time series—measured typically at successive times, spaced according to uniformtime intervals, other periodicity, or other triggers.

An example of a primitive data source is a sensor. Some non-limitingexamples of sensor-type primitive data sources include thermometers,hygrometers, timers, weight scales, barometers, current or voltagemeters, flow meters, strain gauges, and many other types of transducers.Another example of a primitive data source can be an image or videocapturing device, such as a camera of a suitable type. For example, aninfrared camera source can produce primitive data in the form ofperiodic or event triggered thermal images, which from a time-series.Ordinary still-image or video cameras can also similarly behave asprimitive data sources in certain configurations and can similarlyproduce primitive data. These examples of primitive data and primitivedata sources are not intended to be limiting. From this disclosure,those of ordinary skill in the art will be able to conceive many otherforms of primitive data and primitive data sources and the same arecontemplated within the scope of the illustrative embodiments.

Primitive data can be analyzed to compute certain conclusions. Aconclusion is essentially a result of an analysis. The conclusions canbe a fact that can be established or proven by other methods, anestimated or an expected condition, a logical result, or somecombination thereof.

An ordering of conclusions begins at the primitive data. A conclusion iscalled a higher order conclusion or a derivative conclusion, when theconclusion is derived, inferred, computed, or analyzed from theunderlying primitive data, another previously computed conclusion, orsome combination thereof. Some conclusions can be further analyzed tocompute certain other conclusions of even higher order. Generally, thehigher the order of a derived conclusion, the larger is the number ofanalytic steps needed to reach that conclusion from the underlyingprimitive data. While all conclusions are higher order than theprimitive data, a conclusion can be of higher order than someconclusions but of lower order than other conclusions in the ordering ofconclusions.

Analytics is the science of data analysis. An analytic function is acomputation performed in the course of an analysis of supplied dataand/or conclusions. An analytic model is a computational model based ona set of analytic functions. As an example, a common application ofanalytics is the study of operational data using statistical analysis,probability theory, operation research, other techniques, or acombination thereof, in order to discover and understand patterns,predict failures or other issues, and improve operational performance.

An analytic function specification is a code, pseudo-code, scheme,program, or procedure that describes an analytic function. An analyticfunction specification is also known as simply an analyticspecification.

An analytic function instance is an instance of an analytic function,described by an analytic function specification, and executing in a dataprocessing environment. For example, two copies of a softwareapplication that implements an analytic function may be executing indifferent data processing systems in a data processing environment. Eachcopy of the software application would be an example of an analyticfunction instance.

Analytic function instances can depend on one another, or otherwiserelate to one another. For example, one instance of a particularanalytic function may use as an input a conclusion, which is an outputof an instance of another analytic function. The first analytic functioninstance is said to be depending on the second analytic functioninstance.

Analytic configuration, or simply “configuration” is a manner ofdescribing the sequence, order, dependency, or other manner of combiningone or more instances of one or more analytic functions, their inputs,and the conclusions resulting from such combining. In one embodiment, aconfiguration corresponds to code generated in a data processing systemwhere the code invokes the analytical functions for execution in one ormore data processing systems in an order according to the sequence. Forexample, an analytic function that is first in a configuration sequencewill be invoked first, an analytic function that is second in aconfiguration sequence will be invoked second after the first analyticfunction has produced a conclusion, an analytic function that is n-th ina configuration sequence will be invoked after the (n−1)th analyticfunction has produced a conclusion, and so on. When a sequence spansmultiple analytic functions on multiple data processing systems, thosedata processing systems are operated to execute their respectiveanalytic functions according to the sequence in a similar manner.

As an example, a dependency graph can be used to represent therelationships and dependencies among analytic function instances in aconfiguration. The nodes in a dependency graph represent analyticfunction instances, and arcs connecting the nodes represent thedependencies between the nodes. An edge-graph, a tree representation, anetwork path diagram are some other ways of representing therelationships and dependencies among the analytic functions. Thus, byusing a system of logical representations and computations, analyticfunctions and their instances analyze information and events thatpertain to physical things in a given environment.

The illustrative embodiments are directed to solving problemsencountered in implementing smart entities initiatives in smartentities, such as in smart cities. Accordingly, an example of a cityinfrastructure will be used to describe the various illustrativeembodiments. Regardless of the nature of the problem, the approach takenby presently used analytical systems is generally the same. Presently,these systems typically gather relevant data into a centralizedrepository, such as an operational data store or a data warehouse. Thesesystems then execute data mining, predictive analytics, eventcorrelation, and other analytic techniques over the data in thatrepository to infer some result or conclusion upon which some action canbe taken.

The inventors recognize that while these presently used systems are astep forward from the legacy systems or paper based processes used inthe past, there remain some critical limitations in these presently usedanalytical approaches.

For example, the inventors recognize that operating the presently usedanalytics systems first requires consolidating all relevant data. Theinventors recognize that such data consolidation poses severelimitations. For example, the consolidation step introduces latency inthe analytics-based operations management process because of the timeneeded to copy or move the data to a central repository. Furthermore,the analytics become computationally very expensive due to potentiallymassive volumes of real time data feeds, e.g. sensor data or socialmedia streams of citizens, or historical data such as transactionhistories, census data, sensor data, or unstructured data. Additionally,the inventors recognize that consolidation of data is also complicatedby political or governance issues, such as data sharing and ownershipconcerns caused by privacy regulations, competition between cityagencies, and jurisdictional issues.

The inventors further recognize that presently used analytics systemsalso assume and depend upon continued availability and existence of thedata for repeated analyses. The inventors recognize that continuedretention of data becomes problematic as concerns of scale take effect.Preservable data, such as accounts information or engineering data, isoften moved to archives and is not readily available to direct analysis.Some data, such as sensor time series, may be purged from the repositoryand become completely unavailable for future analyses. Thus, theinventors recognize that dependency on consolidated data or continuedexistence thereof is a serious drawback of the presently used analyticssystems.

The inventors further recognize that even when all data is accumulatedand made available, the presently used analytic functions are executedto compute the results at the time something requires attention. Suchexecution is often untimely or impractical as algorithmic complexity anddata volumes increase. Often the time taken to compute a result exceedsthe time window available to take action.

As another drawback of the presently used analytic systems, theinventors recognize that the presently used systems depend onspecifically constructed analytics functions, which are veryspecifically dedicated to solve specific business problem sought to beaddressed. The inventors recognize that any adaptation or changing ofsuch custom analytics functions poses immense cost and risk exposure.The inventors are unaware of any general recognition of these problemsby fellow practitioners.

The illustrative embodiments used to describe the invention generallyaddress and solve the above-described problems and other problemsrelated to presently used methods for data analytics. The illustrativeembodiments provide a method for intelligent spatial enterpriseanalytics.

The illustrative embodiments describe a manner of performing intelligentspatial enterprise analytics (iSEA) to eliminate the dependency on dataaccumulation and persistence, and improve the timeliness oreffectiveness of the results of the analytics. iSEA according to anembodiment provides a robust and scalable approach to large-scaledistributed analytics.

Without implying any limitation thereto, and only for the clarity of thedescription, an example analytics problem is used in several places inthis disclosure. That example analytics problem is, “How can a failurebe predicted in the city's electrical grid?” Another example analyticsproblem may be, “How can a disruption be predicted in the building'swater delivery infrastructure?” Another example analytics problem maybe,

“How can a potential delay be predicted in a branch of a service of thedistrict?”

The inventors have recognized several drawbacks of consolidating datafor analytics. An embodiment operates on remote data. Data is consideredremote when the data is spatially close or proximate within a thresholddistance to a source that produced the data. The embodiment performsanalytics operations on data, as close to the situs of the originationof the data, and in many cases, while that data is in-flight. Data isregarded as being in-flight during the time after the data has beengenerated, and before the data has been stored in a repository or beforethe data has reached a designated or final target system.

An embodiment operates across a collection of heterogeneous computingsystems over a network, such as a wide area network (WAN). For example,an embodiment deploys analytics functions, as analytics agents,spatially as close as possible to the source of primitive data. Ananalytics agent is executable code deployed on a data processing systemor node in a network, to perform or execute an analytic function. In oneembodiment, the analytic agent is programmed to perform a specificanalytic function. In another embodiment, the analytic agent isprogrammed to receive code, message, or instructions to perform ananalytic function identified or supplied in the code, message, orinstructions.

The analytics functions deployed close to a data source in space orgeography perform one or more generic analysis, or standard formanalytics to extract derived conclusions of a certain order from thegiven data. Other analytics functions deployed progressively farther inspace or geography from the data source perform other one or moregeneric analysis, or standard form analytics to extract derivedconclusions of progressively higher orders from their respective inputs.Generally, the analytics functions are spatially dispersed in theenterprise environment at different spatial distances from the datasources. The term “geographical” is a spatial term, meaning physicallocations of the analytics systems and their operation, physicallocations of the analytics functions and their execution, or both.

An analytic function can be broken down into constituent analyticcomponents. For example, in mathematical expressions, an analogousexample of such breakdown is factoring, where a complex equation isbroken down into smaller and easier computations that are often alsofaster to compute than the original complex equation. Similarly, ananalytic function, which when given primitive data provides a finalanalytical answer (highest order conclusion), can be broken down intoseveral smaller or simpler constituent analytical components. In oneembodiment, a constituent analytical component implements an analyticalfunction available in a commonly available standard analytics library.

The constituent analytical components generally produce intermediateanalytical results (initial conclusions and other lower order derivedconclusions). The intermediate analytical results are combinable in oneor more stages of combining, to obtain other intermediate analyticalresults (other derived conclusions), or the final analytical answer (thehighest order conclusion).

The combining of the intermediate analytical results itself can be ananalytical operation of another constituent analytical component. Forexample, some constituent analytical components accept the primitivedata and produce some intermediate analytical results, e.g., initialconclusions. The intermediate analytical results (initial conclusionsand other derived conclusions) of some constituent analytical componentsform inputs to other constituent analytical components, which mayproduce additional intermediate analytical results (other derivedconclusions comparatively higher up the derivation chain) to be passedon in a similar manner, or the final analytical answer (highest orderconclusion).

Such an organization of constituent analytical components can beenvisioned as, without implying a limitation thereto, a hierarchicaltree. For example, starting from the primitive data, to a point wherethe final analytical answer is available, any number of constituentanalytical components can be distributed therebetween, in any sequenceand in any number of layers of nodes. Furthermore, a node in such ahierarchical tree itself comprises a sequence, daisy chain, or someorder of constituent analytical components (collectively referred to assequence). The sequence may arrange constituent analytical functionsserially, parallel, or both.

A standard form analytic function or a general purpose analytic functionis a constituent analytical component as described above. The resultingstandard form analytics or general purpose analysis is an intermediateanalytical result (an initial conclusion or a lower order derivedconclusion) as described above.

Some examples of standard form analytics are described in thisdisclosure without implying a limitation thereto. The embodiment uses ananalytics configuration to configure these standard form analyticsfunctions to find a higher order conclusion of interest from the inputsavailable at the situs of the analytics functions. Given a conclusionthat is desired from analyzing a given set of primitive data, e.g., ahighest order conclusion, a set of standard form or general purposeanalytic functions can be determined using a suitable method of breakingdown the overall analysis into constituent analytical components. Whilefactoring is described as one example of such a method, factoring is notintended to be limiting on the illustrative embodiments.

For example, in order to answer the problem of predicting failures inthe electrical grid system, the primitive data that is relevantoriginates from a large number of geographically (spatially) dispersedprimitive data sources. In an example small-scale grid, there might be20 million smart meters, each sending data updates at 5 minuteintervals. In addition there could be several hundred million sensors,switches, actuators and controllers involved in the system as a whole.Where presently available analytics depend on gathering all of this datainto a central location for analysis, iSEA according to an embodimentinspects the data close to the source data for relevant patterns, trendsor other derived conclusions or higher order conclusions.

iSEA according to an embodiment propagates the derived conclusions orhigher order conclusions, optionally with the primitive data used toderive those conclusions, for further derivation of conclusions of stillhigher order. In one embodiment, the analytics systems to which suchconclusions and data are propagated are spatially situated farther awayfrom the primitive data sources and the analytics systems that derivethe conclusions that are being propagated.

An embodiment further captures the derived conclusions. Having put inplace the ability to operate through decentralized analytics agentsoperating over distributed data, iSEA according to an embodiment furtherdescribes a system of conclusion derivation. Returning to the examplequestion, in order to predict failures in an electrical grid system, itis not sufficient to present all available data for systematictop-to-bottom monolithic analysis, simply because the volume of theconclusions derived therefrom is likely to overwhelm the system or humananalyst that is to act upon those conclusions.

iSEA according to an embodiment derives (N+1) order conclusions from Norder conclusions. Consider, for example, temperature readings for avoltage transformer as relevant data to answer the example analyticsquestion above. An example electrical grid may contain millions oftransformers each with one or more temperature sensors. Consider a setof the temperature readings from a sensor in a transformer to be theprimitive data, or the first order conclusions. The example first orderconclusions in this case reveal the temperature of any given transformercore at a given moment in time. An example first order action triggeredby such a first order conclusion may be to activate a cooling mechanismon the transformer.

iSEA according to an embodiment derives an N+1 (in this case second)order conclusion, from this first order conclusion, for example, a rateof change of temperature with respect to time using a derivativefunction (dTemp/dt). The rate of change of the transformer temperaturein this example forms an example second order conclusion. An examplesecond order action triggered by such a second order conclusion may beto send a command to shutdown the transformer.

iSEA according to an embodiment further analyses these second orderconclusions to further derive third and higher order conclusions. Forexample, perhaps a specification or historical data provides that that atemperature gradient of greater than 5 degrees per second correlateswith a statistical probability of failure of 0.7 over the next 14 daysof operation. As an example, such a comparative conclusion may beavailable by finding patterns of various rates of temperature changes inhistorical data and identifying that of the transformers, where the rateexceeded 5 degrees per second, seventy percent failed within a 14 dayperiod. This probability of failure of the transformer is a third orderconclusion according to an embodiment and relies on standard formpattern matching analytics function.

Because of their custom design to address specific problems only,presently available analytics methods report only the cumulative highestorder conclusion. In contrast, iSEA according to an embodimentiteratively derives lowest order conclusions, and progressivelyincreasing orders or conclusion (1, 2, 3, . . . N, N+1, N+2 . . . )given the primitive data or the first N order conclusions, where N canbe 0 or any positive number. In other words, the prior-art reports asingle level conclusion of the highest configured order whereas anembodiment is configurable to report conclusions of multiple differentlower orders than the highest order of the prior-art.

iSEA according to an embodiment utilizes standard form analyticsfunctions. From a set of standard form analytics functions, anembodiment creates a configuration of a subset of standard formanalytics functions to solve a specific business problem, derive ahigher order conclusion, generate an actionable conclusion, or acombination thereof. The recombination of standard form analyticsfunctions according to an embodiment avoids having to develop largenumbers of custom monolithic analytics functions as are presently used.The embodiment uses a set of standard form analytics functions, eachsupported by standard analytical software libraries such as SPSS (SPSSis a trademark of International Business Machines in the United Statesand in other countries). An embodiment flexibly combines the standardform analytics functions into analytics configurations, anddistributedly deploys these configurations to address complex analyticalproblems over diverse data sets on a massive scale.

Without implying any limitation thereto, some example standard formanalytics functions used in iSEA according to an embodiment includesanalytics functions for pattern identification, root causeidentification, trend identification, and optimization. The patternidentification analytics function operates by looking for instances ofpatterns in the available data sets or streams. In the case of theelectrical grid example described above, the pattern identificationanalytics function identified that a temperature gradient of greaterthan 5 degrees per second within a specific transformer core correlatedwith a statistical probability of failure of 0.7 over the next 14 daysof operation for a transformer. In general, pattern matching operates byreferencing reference data sets, for example, raw historical data, orhistorical conclusions derived through data mining, and either directlyidentifying a corresponding case, or by statistical interpolationbetween known sets to derive a match.

The root cause identification analytics function is in many ways thereverse of pattern matching. This analytics function takes an outcomeand infers a possible cause. Returning to the example of failureprediction in electrical grids, if a transformer core that had failedwere identified, but the likely causes of the failure were not know,root cause analysis could be used to understand the patterns of factorsthat were present when a similar outcome was observed elsewhere. Forexample, likely a trend of rapidly increasing temperature cores would beevident from historical data under similar failure scenarios. Root causeanalysis operates against the same repository of reference data aspattern analysis, but performs the opposite query.

Trend identification analytics function monitors a repository or streamof data for trend indicators. Trend identification does not require aprescribed trend to watch for. Trend identification watches the valuesof selected data properties and seeks to identify trends in thesevalues. For example, in the example temperature data from a transformer,trend identification identifies the increasing trend of the temperatureof the transformer core. Assume that the core typically has atemperature that ranges between 90-100 degrees under normal operatingconditions. As the temperature sensor for the core start to reporttemperatures of 105, 110, 115 degrees, trend identification analyticsfunction used in an embodiment determines two conclusions from thein-flight temperature data—(i) the current value does not matchhistorical expectations, and (ii) the value is increasing at a rate of 5degrees/second.

Optimization analytics function configures a defined set of variables tooptimize a set of values. Optimizers, for example SPSS, operate byassessing the outcome of combinations of input variables in order tomaximize or minimize an outcome. In the case of our example question ofpredicting failures in the electrical grid, an embodiment uses theoptimization analytics function to determine the optimum grid settingsto compensate for the failing transformer and still maintain the desiredsupply levels.

The illustrative embodiments are described with respect to certainprimitive data, forms of data, data sources, locations in a distributedenvironment, analytics functions, configurations, patterns, trends,derived conclusions, events, rules, policies, algorithms, dataprocessing systems, environments, components, and applications usingcertain smart entity initiatives in certain smart entities only asexamples. Any specific manifestations of such artifacts are not intendedto be limiting to the invention. Any suitable manifestation of dataprocessing systems, environments, components, and applications can beselected within the scope of the illustrative embodiments.

Furthermore, the illustrative embodiments may be implemented withrespect to any type of data, data source, or access to a data sourceover a data network. Any type of data storage device may provide thedata to an embodiment of the invention, either locally at a dataprocessing system or over a data network, within the scope of theinvention.

The illustrative embodiments are described using specific code, designs,architectures, protocols, layouts, schematics, and tools only asexamples and are not limiting to the illustrative embodiments.Furthermore, the illustrative embodiments are described in someinstances using particular software, tools, and data processingenvironments only as an example for the clarity of the description. Theillustrative embodiments may be used in conjunction with othercomparable or similarly purposed structures, systems, applications, orarchitectures. An illustrative embodiment may be implemented inhardware, software, or a combination thereof.

The examples in this disclosure are used only for the clarity of thedescription and are not limiting to the illustrative embodiments.Additional data, operations, actions, tasks, activities, andmanipulations will be conceivable from this disclosure and the same arecontemplated within the scope of the illustrative embodiments.

Any advantages listed herein are only examples and are not intended tobe limiting to the illustrative embodiments. Additional or differentadvantages may be realized by specific illustrative embodiments.Furthermore, a particular illustrative embodiment may have some, all, ornone of the advantages listed above.

With reference to the figures and in particular with reference to FIGS.1 and 2, these figures are example diagrams of data processingenvironments in which illustrative embodiments may be implemented. FIGS.1 and 2 are only examples and are not intended to assert or imply anylimitation with regard to the environments in which differentembodiments may be implemented. A particular implementation may makemany modifications to the depicted environments based on the followingdescription.

FIG. 1 depicts a block diagram of a network of data processing systemsin which illustrative embodiments may be implemented. Data processingenvironment 100 is a network of computers in which the illustrativeembodiments may be implemented. Data processing environment 100 includesnetwork 102. Network 102 is the medium used to provide communicationslinks between various devices and computers connected together withindata processing environment 100. Network 102 may include connections,such as wire, wireless communication links, or fiber optic cables.Server 104 and server 106 couple to network 102 along with storage unit108. Software applications may execute on any computer in dataprocessing environment 100.

In addition, clients 110, 112, and 114 couple to network 102. A dataprocessing system, such as server 104 or 106, or client 110, 112, or 114may contain data and may have software applications or software toolsexecuting thereon.

Only as an example, and without implying any limitation to sucharchitecture, FIG. 1 depicts certain components that are useable in anembodiment. For example, assume that devices and systems on network 130are closest to data sources in the depicted example configuration of adistributed environment, devices and systems on network 140 are fartherfrom the devices and systems on network 130, devices and systems onnetwork 102 are farther from the devices and systems on network 140 andfarthest from the data sources in the depicted distributed environment.Primitive data sources 131 and 133 are example data sources thatgenerate primitive data. For example, in case of the example electricalgrid, primitive data source 131 and 133 may be core temperature sensorsat different transformers. Remote analytics systems 132 and 136 are dataprocessing systems closest to primitive data sources 131 and 133 onnetwork 130. According to an embodiment, remote analytics systems 132hosts some combination of analytics functions 134 as described earlier.According to an embodiment, remote analytics systems 136 hosts somecombination of analytics functions 138 as described earlier. Accordingto an embodiment, remote analytics systems 142 on network 140 hosts somecombination of analytics functions 144 as described earlier. Accordingto an embodiment, server 104 hosts some combination of analyticsfunctions 105 as well. Storage 108, or one or more equivalents thereof,hosts historical data 109, acts as a store or repository 111 for derivedconclusions, and acts as a store or repository 113 for analyticsconfigurations. Configuration application 115 in client 112 is usablefor creating or modifying configurations in configurations store 113.

Servers 104 and 106, storage unit 108, and clients 110, 112, and 114 maycouple to network 102 using wired connections, wireless communicationprotocols, or other suitable data connectivity. Clients 110, 112, and114 may be, for example, personal computers or network computers.

In the depicted example, server 104 may provide data, such as bootfiles, operating system images, and applications to clients 110, 112,and 114. Clients 110, 112, and 114 may be clients to server 104 in thisexample. Clients 110, 112, 114, or some combination thereof, may includetheir own data, boot files, operating system images, and applications.Data processing environment 100 may include additional servers, clients,and other devices that are not shown.

In the depicted example, data processing environment 100 may be theInternet. Network 102 may represent a collection of networks andgateways that use the Transmission Control Protocol/Internet Protocol(TCP/IP) and other protocols to communicate with one another. At theheart of the Internet is a backbone of data communication links betweenmajor nodes or host computers, including thousands of commercial,governmental, educational, and other computer systems that route dataand messages. Of course, data processing environment 100 also may beimplemented as a number of different types of networks, such as forexample, an intranet, a local area network (LAN), or a wide area network(WAN). FIG. 1 is intended as an example, and not as an architecturallimitation for the different illustrative embodiments.

Among other uses, data processing environment 100 may be used forimplementing a client-server environment in which the illustrativeembodiments may be implemented. A client-server environment enablessoftware applications and data to be distributed across a network suchthat an application functions by using the interactivity between aclient data processing system and a server data processing system. Dataprocessing environment 100 may also employ a service orientedarchitecture where interoperable software components distributed acrossa network may be packaged together as coherent business applications.

With reference to FIG. 2, this figure depicts a block diagram of a dataprocessing system in which illustrative embodiments may be implemented.Data processing system 200 is an example of a computer, such as servers104 and 106, or clients 110, 112, and 114, or systems 132, 136, or 142in FIG. 1, or another type of device in which computer usable programcode or instructions implementing the processes may be located for theillustrative embodiments.

In the depicted example, data processing system 200 employs a hubarchitecture including North Bridge and memory controller hub (NB/MCH)202 and South Bridge and input/output (I/O) controller hub (SB/ICH) 204.Processing unit 206, main memory 208, and graphics processor 210 arecoupled to North Bridge and memory controller hub (NB/MCH) 202.Processing unit 206 may contain one or more processors and may beimplemented using one or more heterogeneous processor systems.Processing unit 206 may be a multi-core processor. Graphics processor210 may be coupled to NB/MCH 202 through an accelerated graphics port(AGP) in certain implementations.

In the depicted example, local area network (LAN) adapter 212 is coupledto South Bridge and I/O controller hub (SB/ICH) 204. Audio adapter 216,keyboard and mouse adapter 220, modem 222, read only memory (ROM) 224,universal serial bus (USB) and other ports 232, and PCl/PCIe devices 234are coupled to South Bridge and I/O controller hub 204 through bus 238.Hard disk drive (HDD) or solid-state drive (SSD) 226 and CD-ROM 230 arecoupled to South Bridge and I/O controller hub 204 through bus 240.PCl/PCIe devices 234 may include, for example, Ethernet adapters, add-incards, and PC cards for notebook computers. PCI uses a card buscontroller, while PCIe does not. ROM 224 may be, for example, a flashbinary input/output system (BIOS). Hard disk drive 226 and CD-ROM 230may use, for example, an integrated drive electronics (IDE), serialadvanced technology attachment (SATA) interface, or variants such asexternal-SATA (eSATA) and micro- SATA (mSATA). A super I/O (SIO) device236 may be coupled to South Bridge and I/O controller hub (SB/ICH) 204through bus 238.

Memories, such as main memory 208, ROM 224, or flash memory (not shown),are some examples of computer usable storage devices. Hard disk drive orsolid state drive 226, CD-ROM 230, and other similarly usable devicesare some examples of computer usable storage devices including acomputer usable storage medium.

An operating system runs on processing unit 206. The operating systemcoordinates and provides control of various components within dataprocessing system 200 in FIG. 2. The operating system may be acommercially available operating system such as AIX® (AIX is a trademarkof International Business Machines Corporation in the United States andother countries), Microsoft® Windows® (Microsoft and Windows aretrademarks of Microsoft Corporation in the United States and othercountries), or Linux® (Linux is a trademark of Linus Torvalds in theUnited States and other countries). An object oriented programmingsystem, such as the Java™ programming system, may run in conjunctionwith the operating system and provides calls to the operating systemfrom Java™ programs or applications executing on data processing system200 (Java and all Java-based trademarks and logos are trademarks orregistered trademarks of Oracle Corporation and/or its affiliates).

Instructions for the operating system, the object-oriented programmingsystem, and applications or programs, such as analytics functions 105,132, 138, 142, and configuration application 115 in FIG. 1, are locatedon storage devices, such as hard disk drive 226, and may be loaded intoat least one of one or more memories, such as main memory 208, forexecution by processing unit 206. The processes of the illustrativeembodiments may be performed by processing unit 206 using computerimplemented instructions, which may be located in a memory, such as, forexample, main memory 208, read only memory 224, or in one or moreperipheral devices.

The hardware in FIGS. 1-2 may vary depending on the implementation.Other internal hardware or peripheral devices, such as flash memory,equivalent non-volatile memory, or optical disk drives and the like, maybe used in addition to or in place of the hardware depicted in FIGS.1-2. In addition, the processes of the illustrative embodiments may beapplied to a multiprocessor data processing system.

In some illustrative examples, data processing system 200 may be apersonal digital assistant (PDA), which is generally configured withflash memory to provide non-volatile memory for storing operating systemfiles and/or user-generated data. A bus system may comprise one or morebuses, such as a system bus, an I/O bus, and a PCI bus. Of course, thebus system may be implemented using any type of communications fabric orarchitecture that provides for a transfer of data between differentcomponents or devices attached to the fabric or architecture.

A communications unit may include one or more devices used to transmitand receive data, such as a modem or a network adapter. A memory may be,for example, main memory 208 or a cache, such as the cache found inNorth Bridge and memory controller hub 202. A processing unit mayinclude one or more processors or CPUs.

The depicted examples in FIGS. 1-2 and above-described examples are notmeant to imply architectural limitations. For example, data processingsystem 200 also may be a tablet computer, laptop computer, or telephonedevice in addition to taking the form of a PDA.

With reference to FIG. 3, this figure depicts a block diagram of apresently used configuration for data analysis that can be improved byan illustrative embodiment. Primitive data sources 302 are similar toprimitive data sources 131 and 133 in FIG. 1. Network 304 is similar toa combination of networks 102, 130, and 140 in FIG. 1.

Presently, sources 302 send data 303 over network 304 for accumulationor consolidation in repository 306. Customized analytics function 310 inanalytics system 308 analyzes the consolidated data from repository 306to generate conclusion 311. Conclusion 311 is passed to action entity312 for taking any action responsive to conclusion 311.

Presently, as shown in FIG. 3, and as described earlier, often theaction is untimely owing to time needed for the significantcomputational burden from analyzing accumulated data. Conclusion 311 canbe confusing, overwhelming, or both owing to the amount of data overwhich the analytics are performed. Accumulating data in repository 306can be problematic for the various reasons described earlier.

With reference to FIG. 4, this figure depicts an example distributediSEA configuration according to an illustrative embodiment. Distributedenterprise environment 400 comprises an enterprise of numerous devices,equipment, and system that produce data, and numerous analytical systemsor nodes distributed throughout the enterprise for analyzing theproduced data. Primitive data source 402 is an example primitive datasource in primitive data sources 302 in FIG. 3, such as primitive datasource 131 in FIG. 1.

Assume, as an example, that remote analytics system 404 is similar toremote analytics system 132 in FIG. 1, and includes some standard formanalytics functions 406 in the manner of analytics functions 134 inFIG. 1. Further assume that remote analytics system 408 represents oneor more remote analytics systems placed at different proximities fromprimitive data sources 402, similar to remote analytics system 142 inFIG. 1. Such one or more remote analytics systems 408 include variousstandard form analytics functions 410 in the manner of analyticsfunctions 144 in FIG. 1. Assume that analytics system 412 is similar toserver 104 in FIG. 1, and includes some standard form analyticsfunctions 414 in the manner of analytics functions 105 in FIG. 1.

Repository 416 stores and supplies historical data 418, to one or moreof analytics systems 404, 408, and 412, such as to perform analysis forfinding patterns or trends for comparison patterns, trends, or otherconclusions based on current data 403. Historical data 418 is alsousable for determining optimization settings or root cause for use witha current condition in the enterprise environment where source 402 isoperating.

Repository 420 stores derived conclusions 422 from one or more ofanalytics systems 404, 408, and 412. Repository 424 stores analyticsconfigurations 426 and supplies them to one or more of analytics systems404, 408, and 412, such as for configuring a sequence, order, orcombination of analytics functions 406, 410, and 414, respectively.

Configuration application 428 is operable to create or modify aconfiguration in configuration 426. In one embodiment, configurationapplication 428 is operated by a human analyst. The analyst identifies aconclusion (of any order) that is of interest and is to be determined inthe enterprise. The analyst identifies a sequence, order or combinationof analytics functions and inputs that are needed to derive thatconclusion from current data 403. The analyst creates an analyticsconfiguration using configuration application and stores it inconfigurations 426. In another embodiment, a machine, such as anartificial intelligence system, can be programmed to identify higherorder or derivative conclusions from given data, create or modifyanalytics configurations to derive those conclusions from given data 403autonomously without the assistance of a human analyst.

Because of the distributed nature of the analytics, an actionableconclusion can result from any analytics processing in any analyticssystem. For example, analytics system 404 could generate a result thatcould result in an action upon a device or system associated with datasource 402 to make any adjustments, changes, or corrections therein.Such action would be significantly faster as compared to any actiontaken by action entity 312 in FIG. 3. The improved speed results fromthe proximity of the system wherein the actionable conclusion iscomputed to the device on which the action is to be taken, thesignificantly reduced data that participates in the computation of theactionable conclusion, or both. For example, even if the actionableconclusion were computed at the farthest node, e.g., system 412, theconclusion will have been computed much faster owing to thesignificantly less raw data that is propagated up to system 412, otherdownstream systems having performed several intermediate-orderconclusion-findings, or both.

With reference to FIG. 5, this figure depicts a representativeillustration of speed and cost advantages of iSEA in accordance with anillustrative embodiment. Graph 500 represents the computation cost andthe speed (delay) of the actionable conclusions in a presently usedcustom monolithic analytics configuration, such as using system 308 withcustomized analytics function 310 in FIG. 3.

Primitive data 502 includes data 403 in FIG. 4, and similar data fromall other data sources. All primitive data 502 is accumulated andconsolidated in a repository, such as in repository 306 in FIG. 3. Apex504 represents the monolithic analytics execution on consolidatedprimitive data 502. Area 506 represents the amount of computationalresources expended to apply monolithic analytics execution 504 toconsolidated primitive data 502. Distance 508 between primitive data 502and apex 504 represents the delay in arriving at the analytical resultand taking an action.

Graph 550 represents the computation cost and the speed (delay) of theactionable conclusions in an iSEA configuration according to anembodiment, such as using systems 404, 408, and 412 with subsets ofstandard form analytics functions 406, 410, and 414, respectively, inFIG. 4.

Same primitive data 502 that was applied in graph 500 is applied ingraph 550. Because analytics nodes or systems are distributed closer tothe data sources, each node or system only handles a portion ofprimitive data 502 that originates from only some of the primitive datasources. A smaller triangle, e.g., triangle 552 represents, for example,the relative proximity of the analytics node to the data source, and therelatively smaller amount of computational resources expended to derivehigher order conclusions from the portion of primitive data 502 thatforms the base of the smaller triangle.

Analytics nodes or systems at various distances in the distributedprocessing environment are represented as the apexes of the smallertriangles at different layers of the smaller triangles. The derivedconclusions are passed from the apex of a smaller triangle of one layerto the base of a smaller triangle in another layer. Propagation ofderived conclusions for further higher order conclusions derivation inthis manner is much more compact as compared to the volume of theentirety of raw primitive data 502.

The shaded spaces within the smaller triangles together represent thecomputational resources expended in an iSEA configuration according toan embodiment. The empty spaces in the outer triangle of graph 550 thatis not shaded represents the computational resources saved by using aniSEA configuration according to an embodiment. Distances 554 and 556represent the comparatively smaller delays in reaching actionableconclusions by using an iSEA configuration according to an embodiment.

With reference to FIG. 6, this figure depicts a flowchart of a processfor distributed analytics using standard form analytic functions in aniSEA configuration according to an illustrative embodiment. Process 600can be implemented in a distributed enterprise environment such asenvironment 400 in FIG. 4.

The iSEA configuration deploys analytics functions at variousproximities from the primitive data sources operating in the environment(block 602). An analytics system closest or sufficiently close to aprimitive data source in the iSEA configuration receives the primitivedata of the source for determining a higher order conclusion from thatdata (block 604).

The higher order conclusion derived at block 604 becomes an input toanother analytics system in the iSEA configuration. Additional inputs,such as primitive data of interest, comparative conclusions or data froma historical data repository, and one or more analytics configurationsmay also be additional inputs to such other analytics system. Using theconclusions determined at an analytics system downstream, such as atblock 604, and other inputs as needed, another analytics system at adifferent location in the distributed iSEA configuration furtherdetermines another higher order conclusion (block 606).

The analytics system can propagate any raw data that may be of interest(useful for analysis at a later stage) and the conclusions derived atthe analytics system for further higher order conclusions determinationto another analytics system (block 608). Alternatively, or together withblock 608, the analytics system can also generate an actionableconclusion under certain circumstances (block 610). Alternatively, ortogether with blocks 608 and/or 610, the analytics system can also storethe determined conclusion in a derived conclusions repository (block612). Although not shown in process 600, the analytics system at block604 can also generate actionable conclusions and/or store the derivedconclusion in the repository in a similar manner.

The iSEA configuration allows the combination of blocks 606, 608, 610,and 612 to repeat at many times as needed to reach the desired derivedconclusion at any level in the distributed enterprise environment. TheiSEA configuration produces or generates the desired derived conclusionas the analytics result of the analytics processing (block 614). Theanalytics result can take the form of a conclusion or a conclusion, andcan cause an action to be taken or notification to be sent in thedistributed enterprise environment. The configuration ends process 600thereafter or returns to block 604 for another conclusion determination.

With reference to FIG. 7, this figure depicts a process for creating ananalytics configuration for distributed analytics of data using standardform analytics functions in accordance with an illustrative embodiment.Process 700 can be implemented in configuration application 428 in FIG.4.

The application identifies a conclusion that is of interest and is to beestablished from available data (block 702). The application identifies,from a set, a subset of generic analytics functions, e.g., standard formanalytics functions described earlier and other similarly availablefunctions implementing commonly used analytical computations (block704). The subset of generic analytics functions is usable forestablishing the conclusion of interest.

The application determines a sequence, order, or combination in which toexecute one or more instances of the analytics functions in the subset(block 706). The application constructs an analytics configurationdescribing the sequence, order, or combination in which to execute oneor more instances of the analytics functions, together with theirdependencies and inputs (block 708). The analytics configuration isusable for executing the analytics functions at an analytics system ornode and establishing the conclusion of interest.

The application saves the analytics configuration, such as inconfiguration store 424 in FIG. 4 (block 710). The application endsprocess 700 thereafter or returns to block 702 for creating anotheranalytics configuration.

Thus, a computer implemented method is provided in the illustrativeembodiments for intelligent spatial enterprise analytics. While someembodiments are described with respect to some example smart cityinitiatives, such descriptions and such example initiatives are notintended to be limiting on the illustrative embodiments. From thisdisclosure, those of ordinary skill in the art will be able to conceivemany other smart entity initiatives, and adaptations of one or moreembodiments to such other initiatives, and the same are contemplatedwithin the scope of the illustrative embodiments.

For example, some embodiments are described using a temperature sensordata source producing temperature readings time-series in a smartelectric grid. In a similar manner, an embodiment can be adapted toprocess traffic light time-series. For example, a sensor at the trafficlight may generate a time-series of the traffic light states. A firstorder analysis may result in a first order conclusion that the lightmight have a malfunction. Accordingly, a first order action from anembodiment might create an action for a technician to repair the lightor policeman to direct traffic. A higher order conclusion might predictthe traffic that might result from the malfunctioning light, and ahigher order action might cause a diversion strategy to be deployed fordiverting the traffic away from the malfunctioning light.

As another example, a flow sensor in a water main might produce atime-series of water flow data. A low order analysis close to the sensormight compute a low order conclusion that there might be a leak in thewater system. A low order action might shutdown a section of thepipeline for repairs. A higher order conclusion might be that populationaffected by the leak as well as the population serviced by an alternatepipeline which will bear a heavier load due to diversion has to benotified. A still higher order conclusion might find that an inventorylevel of a needed spare part is below a threshold and produce a re-orderparts action for a supplier.

Where an embodiment or a portion thereof is described with respect to atype of device, the computer implemented method, system or apparatus,the computer program product, or a portion thereof, are adapted orconfigured for use with a suitable and comparable manifestation of thattype of device. For example, an embodiment may be implemented in amobile device, such as a tablet or a smartphone device. It iscontemplated within the scope of the illustrative embodiments that sucha mobile device may travel proximate to a data source, and load andexecute an analytic agent suitable for that location in a mannerdescribed herein.

The present invention may be a system, a method, and/or a computerprogram product. The computer program product may include a computerreadable storage medium (or media) having computer readable programinstructions thereon for causing a processor to carry out aspects of thepresent invention.

The computer readable storage medium can be a tangible device that canretain and store instructions for use by an instruction executiondevice. The computer readable storage medium may be, for example, but isnot limited to, an electronic storage device, a magnetic storage device,an optical storage device, an electromagnetic storage device, asemiconductor storage device, or any suitable combination of theforegoing. A non-exhaustive list of more specific examples of thecomputer readable storage medium includes the following: a portablecomputer diskette, a hard disk, a random access memory (RAM), aread-only memory (ROM), an erasable programmable read-only memory (EPROMor Flash memory), a static random access memory (SRAM), a portablecompact disc read-only memory (CD-ROM), a digital versatile disk (DVD),a memory stick, a floppy disk, a mechanically encoded device such aspunch-cards or raised structures in a groove having instructionsrecorded thereon, and any suitable combination of the foregoing. Acomputer readable storage medium, as used herein, is not to be construedas being transitory signals per se, such as radio waves or other freelypropagating electromagnetic waves, electromagnetic waves propagatingthrough a waveguide or other transmission media (e.g., light pulsespassing through a fiber-optic cable), or electrical signals transmittedthrough a wire.

Computer readable program instructions described herein can bedownloaded to respective computing/processing devices from a computerreadable storage medium or to an external computer or external storagedevice via a network, for example, the Internet, a local area network, awide area network and/or a wireless network. The network may comprisecopper transmission cables, optical transmission fibers, wirelesstransmission, routers, firewalls, switches, gateway computers and/oredge servers. A network adapter card or network interface in eachcomputing/processing device receives computer readable programinstructions from the network and forwards the computer readable programinstructions for storage in a computer readable storage medium withinthe respective computing/processing device.

Computer readable program instructions for carrying out operations ofthe present invention may be assembler instructions,instruction-set-architecture (ISA) instructions, machine instructions,machine dependent instructions, microcode, firmware instructions,state-setting data, or either source code or object code written in anycombination of one or more programming languages, including an objectoriented programming language such as Smalltalk, C++ or the like, andconventional procedural programming languages, such as the “C”programming language or similar programming languages. The computerreadable program instructions may execute entirely on the user'scomputer, partly on the user's computer, as a stand-alone softwarepackage, partly on the user's computer and partly on a remote computeror entirely on the remote computer or server. In the latter scenario,the remote computer may be connected to the user's computer through anytype of network, including a local area network (LAN) or a wide areanetwork (WAN), or the connection may be made to an external computer(for example, through the Internet using an Internet Service Provider).In some embodiments, electronic circuitry including, for example,programmable logic circuitry, field-programmable gate arrays (FPGA), orprogrammable logic arrays (PLA) may execute the computer readableprogram instructions by utilizing state information of the computerreadable program instructions to personalize the electronic circuitry,in order to perform aspects of the present invention.

Aspects of the present invention are described herein with reference toflowchart illustrations and/or block diagrams of methods, apparatus(systems), and computer program products according to embodiments of theinvention. It will be understood that each block of the flowchartillustrations and/or block diagrams, and combinations of blocks in theflowchart illustrations and/or block diagrams, can be implemented bycomputer readable program instructions.

These computer readable program instructions may be provided to aprocessor of a general purpose computer, special purpose computer, orother programmable data processing apparatus to produce a machine, suchthat the instructions, which execute via the processor of the computeror other programmable data processing apparatus, create means forimplementing the functions/acts specified in the flowchart and/or blockdiagram block or blocks. These computer readable program instructionsmay also be stored in a computer readable storage medium that can directa computer, a programmable data processing apparatus, and/or otherdevices to function in a particular manner, such that the computerreadable storage medium having instructions stored therein comprises anarticle of manufacture including instructions which implement aspects ofthe function/act specified in the flowchart and/or block diagram blockor blocks.

The computer readable program instructions may also be loaded onto acomputer, other programmable data processing apparatus, or other deviceto cause a series of operational steps to be performed on the computer,other programmable apparatus or other device to produce a computerimplemented process, such that the instructions which execute on thecomputer, other programmable apparatus, or other device implement thefunctions/acts specified in the flowchart and/or block diagram block orblocks.

The flowchart and block diagrams in the Figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods, and computer program products according to variousembodiments of the present invention. In this regard, each block in theflowchart or block diagrams may represent a module, segment, or portionof instructions, which comprises one or more executable instructions forimplementing the specified logical function(s). In some alternativeimplementations, the functions noted in the block may occur out of theorder noted in the figures. For example, two blocks shown in successionmay, in fact, be executed substantially concurrently, or the blocks maysometimes be executed in the reverse order, depending upon thefunctionality involved. It will also be noted that each block of theblock diagrams and/or flowchart illustration, and combinations of blocksin the block diagrams and/or flowchart illustration, can be implementedby special purpose hardware-based systems that perform the specifiedfunctions or acts or carry out combinations of special purpose hardwareand computer instructions.

What is claimed is:
 1. A method for distributed analysis of time-seriesdata in a smart entity environment, the method comprising: receiving,from a data source in the smart entity environment, the time-seriesdata; distributing, in the smart entity environment, an overall analysisof the data to a first analytics node, wherein in a network operatingthe smart entity environment the first analytics node is at a smallerdistance from the data source of the time-series data as compared to adistance between the data source and a second analytics node; performingon the time series data, at the first analytics node, a first portion ofthe overall analysis to produce a first conclusion; routing the firstconclusion to the second analytics node, wherein the second analyticsnode performs a second portion of the overall analysis; and causing,using the first conclusion, from the first analytics node, a firstaction to occur on a component of the smart entity environment, whereinthe data source is associated with the component, wherein thetime-series data is indicative of a condition in the smart entityenvironment, and wherein the component participates in the condition. 2.The method of claim 1, further comprising: routing, in addition to thefirst conclusion, the time-series data to the second analytics node,wherein the second analytics node performs the second portion of theoverall analysis using the first conclusion and the time-series data asinputs.
 3. The method of claim 1, further comprising: producing a secondconclusion from the second portion of the overall analysis; and causing,using the second conclusion, from the second analytics node, a secondaction to occur in the smart entity environment, wherein the secondaction is responsive to the condition in the smart entity environment.4. The method of claim 3, further comprising: routing the secondconclusion to a third analytics node in the smart entity environment,wherein the third analytics node performs a third portion of the overallanalysis.
 5. The method of claim 4, wherein the first portion, thesecond portion, and the third portion together form the overallanalysis.
 6. The method of claim 1, where in the data source is a sensorassociated with the component.
 7. The method of claim 1, wherein thefirst analytics node comprises a first data processing system and thesecond analytics node comprises a second data processing system, furthercomprising: spatially locating, in the smart entity environment, thefirst data processing system at a smaller physical distance from thedata source as compared to a physical distance between the data sourceand the second data processing system.
 8. The method of claim 1, furthercomprising: configuring the first analytics node with a first sequenceof standard form analytics functions to compute the first conclusion;configuring the second analytics node with a second sequence of thestandard form analytics functions to compute a second conclusion.
 9. Themethod of claim 8, further comprising: changing the first sequence to athird sequence, the third sequence configuring the first analytics nodeto compute a third conclusion from the time-series data using thestandard form analytics functions.
 10. The method of claim 1, furthercomprising: identifying the first conclusion as a first conclusion ofinterest; identifying a first subset of a set of standard form analyticsfunctions as being usable to compute the first conclusion of interest;determining an order of execution of at least one instance of at leastone standard form analytics function in the first subset; determining adependency between the at least one instance of the at least onestandard form analytics function and at least one instance of at leastone other standard form analytics function in the first subset;describing the order of execution and the dependency in a firstanalytics configuration; loading the first analytics configuration atthe first analytics node; and configuring, using the first analyticsconfiguration, the first analytics node to compute the first conclusion.11. The method of claim 10, further comprising: identifying the secondconclusion as a second conclusion of interest; identifying a secondsubset of the set of standard form analytics functions as being usableto compute the second conclusion of interest; determining an order ofexecution of at least one instance of at least one standard formanalytics function in the second subset; determining a dependencybetween the at least one instance of the at least one standard formanalytics function and at least one instance of at least one otherstandard form analytics function in the second subset; describing theorder of execution and the dependency in a second analyticsconfiguration; loading the second analytics configuration at the secondanalytics node; and configuring, using the second analyticsconfiguration, the second analytics node to compute the secondconclusion.
 12. The method of claim 11, further comprising: saving thefirst analytics configuration and the second analytics configuration ina configurations repository.
 13. The method of claim 1, furthercomprising: storing the first conclusion and the second conclusion in aderived conclusions repository.
 14. The method of claim 1, furthercomprising: deriving, during the second portion of the overall analysison historical data from a historical data repository, a comparativeconclusion; and using the comparative conclusion in the second portionof the overall analysis to cause a second action from the secondanalytics node in the smart entity environment, wherein the causing thesecond action is responsive to determining that the second conclusionand the comparative conclusion are different according to a criterion.